This invention relates to high-performance 3-D graphics imaging. More particularly, the invention relates to per-fragment operations in a 3D-graphics pipeline.
Three-Dimensional Computer Graphics
Computer graphics is the art and science of generating pictures with a computer. Generation of pictures, or images, is commonly called rendering. Generally, in three-dimensional (3D) computer graphics, geometry that represents surfaces (or volumes) of objects in a scene is translated into pixels stored in a framebuffer and then displayed on a display device.
In a 3D animation, a sequence of still images is displayed, giving the illusion of motion in three-dimensional space. Interactive 3D computer graphics allows a user to change his viewpoint or change the geometry in real-time, thereby requiring the rendering system to create new images on the fly in real time.
In 3D computer graphics, each renderable object generally has its own local object coordinate system and, therefore, needs to be translated (or transformed) from object coordinates to pixel-display coordinates. Conceptually, this translation is a four-step process: 1) translation from object coordinates to world coordinates, the coordinate system for the entire scene, 2) translation from world coordinates to eye coordinates, based on the viewing point of the scene, 3) translation from eye coordinates to perspective-translated eye coordinates and 4) translation from perspective-translated eye coordinates to pixel (screen) coordinates. These translation steps can be compressed into one or two steps by pre-computing appropriate translation matrices before any translation occurs.
(Translation from object coordinates includes scaling for size enlargement or shrink. Perspective scaling makes farther objects appear smaller. Pixel coordinates are points in three-dimensional space in either screen precision (that is to say, pixels) or object precision (that is to say, high-precision numbers, usually floating-point).
Once the geometry is in screen coordinates, it is broken into a set of pixel-color values (that is, xe2x80x9crasterizedxe2x80x9d) that are stored into the framebuffer.
A summary of the prior-art rendering process can be found in Watt, Fundamentals of Three-dimensional Computer Graphics (Addison-Wesley Publishing Company, 1989, reprinted 1991, ISBN 0-201-15442-0, herein xe2x80x9cWattxe2x80x9d and incorporated by reference), particularly Chapter 5, xe2x80x9cThe Rendering Process,xe2x80x9d pages 97 to 113, and Foley et al., Computer Graphics: Principles and Practice, 2nd edition (Addison-Wesley Publishing Company, 1990, reprinted with corrections 1991, ISBN 0-201-12110-7, herein xe2x80x9cFoley et al.xe2x80x9d and incorporated by reference).
FIG. 1 shows a three-dimensional object, a tetrahedron, with its own coordinate axes (xobject, yobject, zobject). The three-dimensional object is translated, scaled and placed in the viewing point""s coordinate system based on (xeye, yeye, zeye) The object is projected onto the viewing plane, thereby correcting for perspective. At this point, the object appears to have become two-dimensional. The object""s z-coordinates, however, are preserved for later use in hidden-surface removal. The object is finally translated to screen coordinates, based on (xscreen, yscreen, zscreen), where zscreen is going perpendicularly into the page. Points on the object now have their x and y coordinates described by pixel location (and fractions thereof) within the display screen and their z coordinates in a scaled version of distance from the viewing point.
Generic 3D-Graphics Pipeline
Many hardware renderers have been developed. See, for example, Deering et al., xe2x80x9cLeo: A System for Cost Effective 3D Shaded Graphics,xe2x80x9d SIGGRAPH93 Proceedings, Aug. 1-6, 1993, Computer Graphics Proceedings, Annual Conference Series (ACM SIGGRAPH, 1993, Soft-cover ISBN 0-201-58889-7 and CD-ROM ISBN 0-201-56997-3, herein xe2x80x9cDeering et al.xe2x80x9d and incorporated by reference), particularly at pages 101 to 108. Deering et al. includes a diagram of a generic 3D-graphics pipeline (that is to say, a renderer, or a rendering system) that it describes as xe2x80x9ctruly generic, as at the top level nearly every commercial 3D graphics accelerator fits this abstraction.xe2x80x9d This pipeline diagram is reproduced here as FIG. 6. (In this figure, the blocks with rounded corners typically represent functions or process operations, while sharp-cornered rectangles typically represent stored data or memory.)
Such pipeline diagrams convey the process of rendering but do not describe any particular hardware. This document presents a new graphics pipeline that shares some of the steps of the generic 3D-graphics pipeline. Each of the steps in the generic 3D-graphics pipeline is briefly explained here. (Processing of polygons is assumed throughout this document, but other methods for describing 3D geometry could be substituted. For simplicity of explanation, triangles are used as the type of polygon in the described methods.)
As seen in FIG. 6, the first step within the floating point-intensive functions of the generic 3D-graphics pipeline after the data input (step 612) is the transformation step (step 614), described above. The transformation step also includes xe2x80x9cget next polygon.xe2x80x9d
The second step, the clip test, checks the polygon to see if it is at least partially contained in the view volume (sometimes shaped as a frustum) (step 616). If the polygon is not in the view volume, it is discarded. Otherwise, processing continues.
The third step is face determination, where polygons facing away from the viewing point are discarded (step 618).
The fourth step, lighting computation, generally includes the set up for Gouraud shading and/or texture mapping with multiple light sources of various types but could also be set up for Phong shading or one of many other choices (step 622).
The fifth step, clipping, deletes any portion of the polygon that is outside of the view volume because that portion would not project within the rectangular area of the viewing plane (step 624). Generally, polygon clipping is done by splitting the polygon into two or more smaller polygons that both project within the area of the viewing plane. Polygon clipping is computationally expensive.
The sixth step, perspective divide, does perspective correction for the projection of objects onto the viewing plane (step 626). At this point, the points representing vertices of polygons are converted to pixel-space coordinates by step seven, the screen space conversion step (step 628).
The eighth step (step 632), set up for an incremental render, computes the various begin, end and increment values needed for edge walking and span interpolation (e.g.: x, y and z coordinates, RGB color, texture map space, u and v coordinates and the like).
Within the drawing-intensive functions, edge walking (step 634) incrementally generates horizontal spans for each raster line of the display device by incrementing values from the previously generated span (in the same polygon), thereby xe2x80x9cwalkingxe2x80x9d vertically along opposite edges of the polygon. Similarly, span interpolation (step 636) xe2x80x9cwalksxe2x80x9d horizontally along a span to generate pixel values, including a z-coordinate value indicating the pixel""s distance from the viewing point. Finally, the z-buffered blending (also referred to as Testing and Blending) (step 638) generates a final pixel-color value. The pixel values include color values, which can be generated by simple Gouraud shading (that is to say, interpolation of vertex-color values) or by more computationally expensive techniques such as texture mapping (possibly using multiple texture maps blended together), Phong shading (that is to say, per-fragment lighting) and/or bump mapping (perturbing the interpolated surface normal).
After drawing-intensive functions are completed, a double-buffered MUX output look-up table operation is performed (step 644). The generic 3D-graphics pipeline includes a double-buffered framebuffer, so a double-buffered MUX is also included. An output lookup table is included for translating color-map values.
By comparing the generated z-coordinate value to the corresponding value stored in the Z Buffer, the z-buffered blend either keeps the new pixel values (if it is closer to the viewing point than previously stored value for that pixel location) by writing it into the framebuffer or discards the new pixel values (if it is farther).
At this step, antialiasing methods can blend the new pixel color with the old pixel color. The z-buffered blend generally includes most of the per-fragment operations, described below.
Finally, digital to analog conversion makes an analog signal for input to the display device.
Per-Fragment Operations
In the generic 3D-graphics pipeline, the z-buffered-blend step actually incorporates many smaller per-fragment operational steps.
Application Program Interfaces (APIs) define a set of per-fragment operations. Open Graphics Library (OpenGL), D3D, Performer, Inventor and B-Render are examples. A review of some exemplary OpenGL per-fragment operations follows so that generic similarities and true differences between the inventive structures and methods and conventional structures and procedures can be more readily appreciated. The language of the OpenGL API is adopted, except as contraindicated herein. (See, for example, Open Architecture Review Board, OpenGL Reference Manual, 2nd edition (Addison-Wesley Developers Press, 1996) and OpenGL Architecture Review Board, OpenGL Programming Guide, 2nd edition (Addison-Wesley, 1997), both incorporated herein by reference.
A framebuffer stores a set of pixels as a two-dimensional array. Each pixel stored in the framebuffer is a set of bits. The number of bits per pixel may vary depending on the particular implementation or context. An implementation may allow a choice in the selection of the number of bits per pixel, but within a context all pixels have the same number of bits.
Corresponding bits from each pixel in the framebuffer form a bitplane. Each bitplane contains a single bit from each pixel. The bits at location (x, y) of all the bitplanes in the framebuffer constitute the single pixel (x, y). Groups of bitplanes form several logical buffers, namely, the color, depth, stencil and accumulation buffers.
The color buffer, in turn, includes a front left, front right, back left, back right and some additional auxiliary buffers. The values stored in the front buffers are the values typically displayed on a display monitor while the contents of the back buffers and auxiliary buffers are invisible and not displayed. Stereoscopic contexts display both the front left and the front right buffers, while monoscopic contexts display only the front left buffer. In general, the color buffers must have the same number of bitplanes, but particular implementations or context may not provide right buffers, back buffers or auxiliary buffers at all, and an implementation or context may additionally provide or not provide stencil, depth or accumulation buffers.
The color buffers generally consist of unsigned-integer color indices (R, G, B) and, optionally, a number xe2x80x9cAxe2x80x9d of unsigned-integer value. The values, however, could be floating-point numbers or signed-integer values. The number of bitplanes in each of the color buffers, the depth buffer (if provided), the stencil buffer (if provided) and the accumulation buffer (if provided) is fixed on a per-context basis. If an accumulation buffer is provided, it has at least as many bitplanes per R, G and B color component as do the color buffers.
A rasterization-produced fragment with window coordinates of (xWlNDOW, yWINNDOW) modifies the pixel in the framebuffer at those coordinates based on a number of tests, parameters and conditions. Among the several tests typically performed sequentially, beginning with a fragment and its associated data and finishing with a final output stream to the framebuffer, are (in the order performed, with some variation among APIs): pixel-ownership test, scissor test, alpha test, color test, stencil test, depth test, blending, dithering and logic operations. Each of these tests or operations is briefly described below. (OpenGL does not provide for an explicit color test between the alpha and stencil tests. OpenGL per-fragment operations are applied after all the color computations.)
Ownership Test
The pixel-ownership test determines if the pixel at location (xWINDOW, yWINDOW) in the framebuffer is currently owned by the graphics-language context. If it is not, the window system decides the fate of the incoming fragment. Possible results are that the fragment is discarded or that some subset of the subsequent per-fragment operations are applied to the fragment. Pixel ownership allows the window system to properly control the GL""s behavior.
Assume that in a computer having a display screen, one or several processes are running and that each process has a window on the display screen. For each process, the associated window defines the pixels to which the process wants to write or render. When there are two or more windows, the window associated with one process may be in front of the other window associated with another process, behind that other window or along with the other window entirely visible. Since there is only a single framebuffer for the entire display screen, the pixel-ownership test determines which process and associated window owns each of the pixels. If a particular process does not xe2x80x9cownxe2x80x9d a pixel, it fails the pixel-ownership test relative to the framebuffer, and that pixel is thrown away.
Under the typical paradigm, the pixel-ownership test is run by each process. For a given pixel location in the framebuffer, that pixel passes the pixel-ownership test for at most one of the processes and fails the pixel-ownership test for all other processes. Only one process owns a particular framebuffer pixel at the same time.
In some rendering schemes, the pixel-ownership test may not be particularly relevant. For example, if the scene is being rendered to an off-screen buffer and subsequently block transferred (xe2x80x9cblittedxe2x80x9d) to the desktop, pixel ownership is not particularly relevant. Each pixel that a process tests automatically or necessarily passes the pixel-ownership test (if it is even executed) because each process effectively owns its own off-screen buffer and nothing is in front of that buffer.
If for a particular process, the pixel is not owned by that process, writing a pixel value to that location is unnecessary. All subsequent processing for that pixel may be ignored. In a typical workstation, all the data associated with a particular pixel on the screen is read during rasterization. All information for any polygon that feeds that pixel is read, including information as to the identity of the process that owns that framebuffer pixel, as well as the z-buffer, the color value, the old color value, the alpha value, stencil bits and so forth.
If a process owns the pixel, then the other downstream processes are executed (for example, scissor test, alpha test and the like).
Scissor Test
The scissor test determines if (xWINDOW, yWINDOW) lies within a scissor rectangle defined by four coordinate values corresponding to a left bottom (left, bottom) coordinate, a width of the rectangle and a height of the rectangle. (See, for example, the OpenGL procedure Scissor(left, bottom, width, height). If leftxe2x89xa6xWINDOW less than left+width and bottomxe2x89xa6yWINDOW less than bottom+height, then the scissor test passes. Otherwise, the scissor test fails, and the particular fragment being tested is discarded.
In simple terms, a scissor rectangle defines a screen-aligned region. This scissor rectangle is useful in that only pixels from a polygon that fall in that screen-aligned scissor rectangle change. In the event that a polygon straddles the scissor rectangle, only those pixels that are inside the rectangle may change. An implementation may allow more than one scissor rectangle. A scissor rectangle list can be used for rendering to a window that is partially obscured such that the visible portion of the window consists of more than one rectangular region.
Just as with the pixel-ownership test, the scissor test provides means for discarding pixels and/or fragments before they actually get to the framebuffer to cause the output to change.
When a polygon comes down the pipeline, the pipeline calculates everything it needs to determine the z-value and color of that pixel. Once z value and color are determined, that information helps to determine what information is placed in the framebuffer, thereby determining what is on the display screen.
Stipple Test
The stipple test uses a 32xc3x9732-bit window-aligned stipple pattern. The stipple pattern is a mask of 0s and 1s. The stipple pattern is tiled on the window. The stipple test passes if the bit in the stipple pattern at (xWINDOW, yWINDOW) is set, i.e. is 1. Otherwise, the stipple test fails, and the particular fragment being tested is discarded.
Alpha Test
Color is defined by four values, red (R), green (G), blue (B) and alpha (A). The RGB values define the contribution from each of the primary colors, and alpha is related to the transparency. Typically, color is a 32-bit value, 8-bits for each component, though such representation is not limited to 32-bits. The alpha test compares the alpha value of a given pixel to an alpha-reference value. Any pixel not passing the alpha test is thrown away or otherwise discarded.
The type of comparison may also be specified. For example, the comparison may be a greater-than operation, a less-than operation and so forth. If the comparison is a greater-than operation, then the pixel""s alpha value has to be greater than the reference to pass the alpha test. So if the pixel""s alpha value is 0.9, the reference alpha is 0.8 and the comparison is greater-than, then that pixel passes the alpha test.
The alpha test is a per-fragment operation and happens after all of the fragment coloring calculations and lighting and shading operations are completed. Each of these per-fragment operations may be thought of as part of the conventional z-buffer blending operations.
Color Test
The color test is similar to the alpha test described hereinbefore, except that rather than performing the magnitude or logical comparisons between the pixel alpha (A) value and a reference value, the color test performs a magnitude or logical comparison between one or a combination of the R, G or B color components and reference value(s). Although for the alpha test, one typically has one value for each component, for the color test there are effectively two values per component, a maximum value and a minimum value.
The comparison test may be, for example, greater-than, less-than, equal-to, greater-than-or-equal-to, xe2x80x9cgreater-than-c1 and less- than c2,xe2x80x9d where c1 and c2 are predetermined reference values, and so forth. One might, for example, specify a reference minimum R value and a reference maximum R value, such that the color test passes only if the pixel R value is between that minimum and maximum. The color test might be useful to provide blue-screen functionality, for example.
Stencil Test
The stencil test conditionally discards a fragment based on the outcome of a comparison between a value stored in a stencil buffer at location (xWINDOW, yWINDOW) and a reference value. If the stencil test fails, the incoming fragment is discarded, although the corresponding stencil buffer value may be modified in accordance with the specified stencil operation to be carried out on failing the stencil test.
When an object is rendered into the framebuffer, a tag having the stencil bits is also written into the framebuffer. These stencil bits are part of the pipeline state. The type of the stencil test to perform can be specified at the time the geometry is rendered.
The stencil bits are used to implement various filtering, masking or stenciling operations. For example, if a particular fragment ends up affecting a particular pixel in the framebuffer, then the stencil bits can be written to the framebuffer along with the pixel information.
Several stencil comparison functions are permitted such that the stencil test passes never, always or if the reference value is less than, less than or equal to, equal to, greater than or equal to, greater than, or not equal to the masked stored value in the stencil buffer.
The reference value and the comparison value can have multiple bits, typically 8 bits so that 256 different values may be represented.
Depth-Buffer Test
The depth-buffer test discards the incoming fragment if a depth comparison fails. The comparison is programmatically enabled or disabled. When the depth test is disabled, the depth comparison and subsequent possible updates to the depth-buffer value are bypassed, and a fragment is passed to the next operation. The stencil bits are also involved and may be modified even if the test is bypassed. In this case, the stencil value is modified as if the depth-buffer test passed.
If the depth test is enabled, the depth comparison takes place and the depth buffer and stencil value may subsequently be modified.
Depth comparisons are implemented in which possible outcomes are as follows: the depth-buffer test passes never, always or if the incoming fragment""s zWINDOW value is less than, less than or equal to, equal to, greater than, greater than or equal to, or not equal to the depth value stored at the location given by the incoming fragment""s (xWINDOW, yWINDOW) coordinates. If the depth-buffer test fails, the incoming fragment is discarded. The stencil value at the fragment""s (xWINDOOW, yWINDOW) coordinate is updated according to the function currently in effect for depth-buffer test failure. Otherwise, the fragment continues to the next operation and the value of the depth buffer at the fragment""s (xWINDOW, yWINDOW) location is set to the fragment""s zWINDOW value. In this case the stencil value is updated according to the function currently in effect for depth-buffer test success.
Blending
Blending combines the incoming fragment""s R, G, B and A values with the R, G, B and A values stored in the framebuffer at the incoming fragment""s (xWINDOW, yWINDOW) location. This blending is typically dependent on the incoming fragment""s alpha value (A) and that of the corresponding framebuffer stored pixel. (In the following discussion, xe2x80x9cCsxe2x80x9d refers to the source color for an incoming fragment, xe2x80x9cCdxe2x80x9d refers to the destination color at the corresponding framebuffer location, and xe2x80x9cCcxe2x80x9d refers to a constant color in-the GL state. Subscripts of xe2x80x98s,xe2x80x99 xe2x80x98dxe2x80x99 and xe2x80x98cxe2x80x99 respectively denote individual RGBA components of these colors.)
Generally speaking, blending is an operation that takes color in the framebuffer and the color in the fragment and blends them together. The manner in which blending is achieved, that is, the particular blending function, may be selected from various alternatives for both the source and destination.
For example, an additive-type blend is available wherein a blend result (C) is obtained by adding the product of a source color (Cs) by a source weighting-factor quadruplet (S) to the product of a destination color (Cd) and a destination weighting-factor quadruplet (D), that is, C=CsS+CdD. Alternatively, the blend equation may be a subtraction (C=CsSxe2x88x92CdD), a reverse subtraction, (C=CdDxe2x88x92CsS), a minimum function, (C=min(Cs, Cd)), or a maximum function, (C=max(Cs, Cd)). The blending equation is evaluated separately for each color component and its corresponding weighting coefficient. Each of the four R, G, B, A components has its own weighting factor.
The blending test (or blending equation) is part of the pipeline state and can potentially change for every polygon but, more typically, changes only for an object made up of several polygons.
In general, blending is performed only after other tests such as the pixel-ownership test and stencil test have passed. Then it is clear that the pixel or fragment under consideration would or could have an effect in the output.
Dithering
Dithering selects between two color values or indices. In RGBA mode, the value of any of the color components is essentially a fixed-point value, c, with m bits to the left of the binary point, where m is the number of bits allocated to that component in the framebuffer. For each c, dithering selects a value cxe2x80x2 such that cxe2x80x2∈{max{0, Ceiling(c)-1}, Ceiling(c)}. In color index mode, the same rule applies with c being a single-color index. This selection may depend on the xWINDOW and yWINDOW coordinates of the pixel. (The value of c cannot be larger than the maximum value representable in the framebuffer for the color component.)
Although many dithering algorithms are possible, a dithered value produced by any algorithm generally depends on only the incoming value and the fragment""s x and y window coordinates. When dithering is disabled, each color component is truncated to a fixed-point value with as many bits as there are in the corresponding framebuffer component.
Logical Operations
A final logical operation applies between the incoming fragment""s color or index values and the color or index values stored in the framebuffer at the corresponding location. The result of the logical operation replaces the values in the framebuffer at the fragment""s (x, y) coordinates. Various logical operations may be implemented between source (s) and destination (d), including for example: CLEAR, SET, AND, NOOP, XOR, OR, NOR, NAND, INVERT, COPY, INVERTED AND, EQUIVALENCE, REVERSE OR, REVERSE AND, INVERTED COPY and INVERTED OR. Logical operations are performed independently for each color-index buffer that is selected for writing or for each red, green, blue and alpha value of each color buffer that is selected for writing.
Antialiasing
Pixels are the smallest individually controllable element of the display device. However, with images quantized into discrete pixels, spatial aliasing occurs. A typical aliasing artifact is a xe2x80x9cstaircasexe2x80x9d effect caused when a straight line or edge cuts diagonally across rows of pixels.
Some rendering systems reduce aliasing effects by dividing pixels into sub-pixels, where each sub-pixel can be colored independently. When the image is to be displayed, the colors for all sub-pixels within each pixel are blended together to form an average color for the pixel. A renderer that uses up to 16 sub-pixels per pixel is described in Akeley, xe2x80x9cRealityEngine Graphics,xe2x80x9d SIGGRAPH93 Proceedings, Aug. 1-6, 1993, Computer Graphics Proceedings, Annual Conference Series, pages 109 to 116 (ACM SIGGRAPH, New York, 1993, Softcover ISBN 0-201-58889-7 and CD-ROM ISBN 0-201-56997-3, herein xe2x80x9cAkeleyxe2x80x9d and incorporated by reference).
Carpenter, xe2x80x9cThe A-buffer, an Antialiased Hidden Surface Method,xe2x80x9d SIGGRAPH 1984 Conference Proceedings, pp.103-108 (July 1984, herein xe2x80x9cCarpenterxe2x80x9d and incorporated by reference), describes another prior-art antialiasing method, the A-Buffer method. (Akeley also describes this technique.) The A-buffer is an antialiasing technique that reduces aliasing by keeping track of the percent coverage of a pixel by a rendered polgon.
The sub-pixel antialiasing approach is not without its problems. Assuming each pixel is divided into an n*m number of sub-pixels, some, if not all, of computations in the fragment-operations pipeline increase in number by a factor of n*m.
A counter approach to the n*m sub-pixels is the use of samples. Given n*m sub-pixels per pixel, prior-art fragment-operations pipelines select a fixed number H of these n*m sub-pixels from H fixed locations to represent the entire pixel. The fragment operations are applied to the H samples. At the end of the pipeline, each of the H samples is given the same weight in re-creating the pixel.
Additionally, all of the per-fragment operations of prior-art fragment-operations pipelines are done on a per-pixel basis where samples and sub-pixels have not been implemented. Where sub-pixels or samples or pixels are implemented, all of the pre-fragment operations are done on a respective per-sub-pixel or per-sample basis.
However, fixing the number, location and weight of samples restricts the flexibility of the fragment-operations pipeline and decreases the effectiveness of its techniques. Likewise, performing all fragment operations on a per-pixel, per-sub-pixel or per-sample basis restricts the flexibility of the fragment-operations pipeline and decreases its effectiveness.
The main drawback to the A-buffer technique is the need to sort polygons front-to-back (or back-to-front) at each pixel in order to get acceptable antialiased polygons.
Accordingly, there is a need for a multi-dimensionally flexible per-fragment pipeline. There is always a need for an antialiasing method that improves on the rendered image.
These and other goals of the invention will be readily apparent to one of skill in the art on reading the background above and the description below.
Herein are described apparatus and methods for rendering 3D-graphics images with and without anti-aliasing. In one embodiment, the apparatus include a port for receiving commands from a graphics application, an output for sending a rendered image to a display and a fragment-operations pipeline, coupled to the port and to the output, the pipeline including a stage for performing a fragment operation on a fragment on a per-pixel basis, as well as a stage for performing a fragment operation on the fragment on a per-sample basis.
In one embodiment, the stage for performing on a per-pixel basis is one of the following: a scissor-test stage, a stipple-test stage, an alpha-test stage or a color-test stage. The stage for performing on a per-sample basis is one of the following: a Z-test stage, a blending stage or a dithering stage.
In another embodiment, the apparatus programmatically selects whether to perform a stencil test on a per-pixel or a per-sample basis and performs the stencil test on the selected basis.
In another embodiment, the apparatus programmatically selects a set of subdivisions of a pixel as samples for use in the per-sample fragment operation and performs the per-sample fragment operation, using the programmatically selected samples.
In another embodiment, the apparatus programmatically allows primitive based anti-aliasing, i.e. the anti-aliasing may be turned on or off on a per-primitive basis.
In another embodiment, the apparatus programmatically performs several passes through the geometry. The apparatus selects the first set of subdivisions of a pixel as samples for use in the per-sample fragment operation and performs the per-sample fragment operation, using the programmatically selected samples. It then programmatically selects a different set of the pixel subdivisions as samples for use in a second per-sample fragment operation and then performs the second per-sample fragment operation, using the programmatically selected samples.
The color values resulting from the second pass are accumulated with the color values from the first pass. Several passes can be performed to effectively increase the number of samples per pixel. The sample locations for each pass are different and the pixel color values are accumulated with the results of the previous passes.
The apparatus programmatically selects a set of subdivisions of a pixel as samples for use in the per-sample fragment operation, programmatically assigns weights to the samples in the set and performs the per-sample fragment operation on the fragment. The apparatus programmatically determines the method for combining the color values of the samples in a pixel to obtain the resulting color in the framebuffer at the pixel location. In addition, the apparatus programmatically selects the depth value assigned to a pixel in the depth buffer from the depth values of all the samples in the pixel.
The apparatus includes a method to clear the color, depth, and stencil buffers partially or fully, without a read-modify-write operation on the framebuffer.
The apparatus includes a method for considering per-pixel depth values assigned to the polygon as well as the depth values interpolated from those specified at the vertices of the polygon.
The apparatus includes a method for considering per-pixel stencil values assigned to the polygon in stencil test, as well as the specified stencil reference value of the polygon.
The apparatus includes a method for determining if any pixel in the scene is visible on the screen without updating the color buffer.